In computer systems security, role-based access control (RBAC) is an approach to restricting system access to authorized users. RBAC is currently used by many enterprises. In accordance with an RBAC scheme, security roles are created for various job functions within an organization. Permissions to view certain information and perform certain actions are associated with specific security roles. Employees or other system users are assigned particular security roles, and through such assignments acquire the permissions associated with those roles. Since users are not assigned permissions directly, but only acquire them through their security role (or roles), management of individual user rights becomes a matter of simply assigning appropriate security roles to the user's account. This simplifies common operations, such as adding a user, changing a user's department, or the like.
Software applications exist that allow a user to view information and perform actions by interacting with a user interface (UI), where the information that can be viewed and the actions that can be performed depend upon the security role(s) currently assigned to the user in accordance with an RBAC scheme. By way of example, SYSTEM CENTER 2012 CONFIGURATION MANAGER, published by Microsoft Corporation of Redmond Wash., is a systems management software product that enables an administrator to access and create various security roles having different sets of permissions and to assign one or more of these security roles to a user. When such user logs into SYSTEM CENTER 2012 CONFIGURATION MANAGER, he is presented with an administrative console UI that enables him to view only that information and perform only those actions that are authorized for his assigned security role(s). However, this is only one example, and other software applications exist that determine the information that can be viewed and/or the actions that can be performed by a user via a UI based on one or more security roles assigned thereto.
When an administrator interacts with a software application such as was described in the preceding paragraph to access or create a security role, such administrator may have a difficult time determining what information and actions will be made accessible via the application UI for the security role. This may be the case, for example, where there is a complex relationship between the permissions that can be assigned to the security roles and the information/actions that become accessible via the UI as a result of assigning such permissions. This may also be the case, for example, where the number of different operations that may be associated with each security role is very large.
Conventionally, one way that an administrator can determine what information can be viewed and what actions can be performed by a particular security role or combination of security roles via the UI is to create an actual user account, assign the particular security role(s) to the user associated with the user account, and then log on to the application as the user to see what information can be viewed and what actions can be performed via the application UI. However, this approach is extremely inefficient, cumbersome, and time consuming.
In certain software applications that support RBAC, it may not be easy for an administrator to determine which security roles have been assigned to a particular user. For example, such a software application may enable one or more security roles to be assigned to a user group that includes the particular user, but may display only the association between the security role(s) and the user group. Furthermore, an administrator may have a difficult time determining what information and actions will be made accessible to a particular user via the application UI based on the user's assigned security role(s). One way to obtain such information would be for the administrator to log on to the application as the user. However, such log on procedure typically requires entry of a password that is known only to the user and is therefore not accessible to the administrator. Furthermore, such an approach is extremely inefficient, cumbersome and time consuming.